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(57) Abstract: The area of the invention belongs to the transport technologies in UTRAN. This invention concerns a method for 
multiplexing a data stream, onto a transport bearer between an originating network node and a receiving network node in a telecom- 
munications network. This is done in order to ensure the effective usage of transport resources over the two interfaces, i.e. Iub/Iur. 
To accomplish this the RNC and/or Node B/RNC should check if the there already exists a transport bearer, which can be utilised 
for HS-DSCH transport over Iub/Iur interface. Because of this a transport bearer identification code or transport bearer id is needed 
to identify this bearer between RNC and Node B/RNC, 
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Method for multiplexing data streams onto a transport bearer 
between an originating network node and a receiving network 
node . 

The present invention relates to telecommuni- 
cation systems* In particular, the present invention 
5 relates to a novel and improved method for multiplex- 
ing data streams onto a transport bearer between an 
originating network node and a receiving network node. 

BACKGROUND OF THE IJ3VENTION 

In the current specifications of the third 

10 generation mobile networks (referred to as UMTS, Uni- 
versal Mobile Telecommunication System), the system 
utilises the same well-known architecture that has 
been used by all main second generation systems. A 
block diagram of the system architecture of the cur- 

15 rent UMTS network is presented in figure 1. The UMTS 
network architecture includes the core network (CSS), 
the UMTS terrestrial radio access network (UTRAN) , and 
the user equipment (UE) ♦ The core network is further 
connected to the external networks, i.e. the Internet, 

20 PSTN (Public Switched Telephone Network) and/or ISDN 
(Integrated Digital Services Network) . 

The UTRAN architecture consists of several 
radio network subsystems (RKS) , The RNS is further di- 
vided into the radio network controller (RNC) and sev- 

25 eral base stations (BTS , referred to as Node B in the 
3GPP specifications) , In this architecture there are 
several different connections between the network ele- 
ments. The lu interface connects CM to UTRAN. The Iur 
interface enables the exchange of signalling informa- 

30 tion and user plane information between two RHCs. 
There is no equivalent interface to Iur in the archi- 
tectures of the second generation mobile networks. The 
radio network layer (RNL) signalling protocol across 
the Iur interface is called the radio network subsys- 

3 5 tern application part (RNSAP) ♦ The RNSAP is terminated 
at both ends of the Iur interface by an KNC* The Iub 
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interface connects an RNC and a Node B« The Xub inter- 
face allows the RNC to indicate the required radio re- 
sources to the Node , for example, to add and delete 
cells controlled by Node B to support communication of 
5 dedicated connection between UE and C-RNC (Control 
RNC) , information used to control the broadcast and 
paging channels, and information to be transported on 
the broadcast and paging channels . One Node B can 
serve one or multiple cells. UE is connected to Node B 

10 through the Uu radio interface. UE further consists of 
a subscriber identity module (USIM) and mobile equip- 
ment (ME) . They are connected by the Cu interface. 
Connections to external networks are made through 
Gateway MSC (Mobile Services Switching centre) (to- 

15 wards circuit switched networks) or GGSN [Gateway GPRS 
(Group Packet Radio System) Support Node] (towards 
packet switched networks) * 

The general protocol model for UTRAN Inter- 
faces is depicted in figure 2, and described in detail 

2D in the following. The structure described is based on 
the principle that the layers and planes are logically 
independent of each other. 

The Protocol Structure consists of two main 
layers, Radio Network Layer and Transport Network 

2 5 Layer (TNL) . These are presented in the horizontal 
planes of figure 2 . All UTRAN related issues are visi- 
ble only in the Radio Network Layer , and the Transport 
Network Layer represents the standard transport tech- 
nology that is selected to be used for UTRAN. UTRAN 

30 has certain specific requirements for TNL. For in- 
stance, the real time requirement, i.e. the transmis- 
sion delay has to be controlled and kept small. 

In the HS-DSCH {HS-DSCH, High Speed Downlink 
Shared Channel; HSDPA High Speed Downlink Packet Ac- 

35 cess) specification work the basic assumption is that 
the same transport solution that has been used for 
DSCH will be used for HS-DSCH also. In this applica- 
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tion the term HS-DSCH is used to describe the channel 
or data stream between CRNC and Node B on Tub inter- 
face and therefore it should not mixed up with the 
HSDPA related transport channel, which is an internal 
5 channel between MAC -hs (Medium Access Control) and LI 
(Layer 1) in Node B. In this solution dedicated 
transport bearer is reserved separately for each DSCH 
data stream between SHNC (Serving RHC) and Mode B . 
Figure 3 shows the radio interface protocol architec- 

10 ture with termination points. In logical model MAC-hs, 
which is inserted in Node B, locates below MAC-c/sh, 
which further is implemented in CRNC. The HS-DSCH FP 
(frame protocol) will handle the data transport from 
SRNC to CRHC (if the lur interface is involved) and 

IE between CRNC and the Node B. The architecture supports 
both FDD (Frequency Division Duplex) and TDD (Time Di- 
vision Duplex) modes of operation, though in the case 
of TDD, some details of the associated signalling for 
HS-DSCH are different. 

2 0 The basic structure of KS-DSCH is assumed to 

be based on two architectures; an RNC-based architect 
ture consistent with Release f 99 architecture and a 
Node B-based architecture for scheduling. Moving the 
scheduling to the Node B enables a more efficient im- 
25 plementation of scheduling by allowing the scheduler 
to work with the most recent channel information. The 
scheduler can adapt the modulation to better match the 
current channel conditions and fading environment. 
Moreover, the scheduler can exploit the multi-user di- 

3 0 versity by scheduling only those users in constructive 

fades. Furthermore, the HSDPA proposal has the addi- 
tional potential to improve on the RNC-based HARQ ar- 
chitecture in both TIE memory requirements and trans- 
mission delay. The scheduler for the HS-DSCH is there- 
35 fore located in the Node B, wherein the HS-DSCH refers 
to the transport channel, which locates between MAC - 
hs and LI internally in Node B. 
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There is no identification IE in Iub/Iur FP 
{FP, Frame Protocol) to identify a certain UK. There- 
fore the dedicated transport bearers were needed to 
identify a particular XJE to enable the efficient usage 
5 of power control function over the radio interface. 
This means that number of required transport bearers 
to be reserved between SKNC and Node B is the same as 
the number of DSCH data streams. One US can have sev- 
eral data streams* To make the system work properly, 

10 capacity i.e. bandwidth for each transport bearer has 
to be reserved according the reserved DSCH capacity 
over the radio interface. E.g. if the DSCH capacity in 
the radio interface is 512 kbp's and there are 10 data 
streams sharing the channel the maximum required 

15 transport capacity is 10 times 512 kbps over Iub in- 
terface to ensure the QoS . And as the scheduling is 
done by MAC-sh in CRNC only one transport bearer is 
used in certain time frame. As a result a lot of band- 
width is wasted. This increases the need of the band- 

20 width resources. 

The invention is characterised by what is 
disclosed in the independent claims. 

SUMMARY OF THE INVENTION 

25 This invention concerns a method for multi- 

plexing a data stream onto one transport bearer be- 
tween an originating network node and a receiving net- 
work node in a telecommunications network. This is 
done in order to ensure the effective usage of trans- 

30 port resources over the two interfaces, i.e. Iub/Iur. 
To accomplish this the RNC and/or Node B/RNC should 
check if the there already exists a transport bearer, 
which can foe utilised for HS-DSCH data stream over 
Iub/Iur interface. Because of this a transport bearer 

35 identification code or transport bearer id is needed 
to identify this bearer between RNC and Node B/RNC. 



WO 03/044999 



PCT7FI01/91012 



The scheduling to the radio interface for 
DSCH is done by MAC-sh function located in CRNC 
whereas in the RS-DSCB. the scheduling, wherein the HS- 
DSCH refers to the transport channel , which locates 
5 between MAC -he and LI internally in Node B, to the 
radio interface shall be done by MAC-hs, which is lo- 
cated in Node B. Therefore the identification of the 
transport bearer can be done by other means than using 
dedicated transport bearers between SRNC/CRNC and Node 

10 B. Enabling the multiplexing of HS-DSCH data streams 
to the same transport bearer the huge amount: of trans- 
port resources can be saved* 

Before sending any message to Node B/RNC to 
request a new transport bearer for HS-DSCH data stream 

15 RNC checks if there already exists a transport bearer 
between RNC and Node B/RNC, which can be used for this 
purpose. If there does not exist any transport bearer, 
identified by transport bearer id, that can be used to 
carry a new HS-DSCH data stream, RNC sends the request 

20 for a transport bearer for HS-DSCH data stream without 
transport bearer id to indicate to Node B/RNC that a 
new transport bearer is needed. 

If the transport bearer that can be used ex- 
ists, RHC includes the transport bearer id to the re- 

25 quest message to indicate to Node B/RNC which existing 
transport bearer it likes to use for this new HS-DSCH 
data stream. If Node B/RNC accepts the request, no ad- 
ditional transport layer information shall be included 
to the response message. Otherwise Node B/RNC includes 

30 a new transport layer information to the reply message 
to indicate that the new transport bearer is needed, 

There is also another possibility for Node 
B/RNC to decide the usage of the transport bearer. In 
this case R£JC will send the HS-DSCH re- 

35 quest/modification message to Node B/RNC without any 
further information. Then receiving Node B/RNC will 
decide whether it is to assign a new transport bearer 
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or to use existing transport bearer. In case it de- 
cides to assign a new transport bearer, it will reply 
with new transport address and new transport bearer 
id, If it decides to use existing transport bearer it 
5 will reply with only the existing transport bearer id 
selected to be used as a shared transport bearer for 
the new HS-DSCH data stream by Mode B/RNC, without new 
transport address . 

In the present specification there is no Id 

10 that can be used as a transport bearer id to identify 
on the Radio Network Layer a certain already existing 
transport bearer out of a particular UE context be- 
tween RNC and Node B. It is impossible to indicate to 
Node B/RJSJC by RNC that one of the existing transport 

15 bearers can be used to carry another data stream for 
different or for the same UE* 

To enable the transport bearer selection 
functionality for HS-DSCH a new transport bearer id 
shall be introduced between RNC and Node B/RJSFC in 

20 NBAP/RNSAP messages. When a new transport bearer serv- 
ice instance is created/ a transport bearer id is as- 
signed to it by the RNL application. This transport 
bearer id needs to be unique at least per an inter- 
face/ i,e. between the two UTRAN nodes terminating the 

25 corresponding RNL application protocol. The transport 
bearer ID is stored by both originating and receiving 
nodes (RNC/ RNC/Node B) for the lifetime of the corre- 
sponding transport bearer service instance. 

To ensure the uniqueness of the transport 

30 bearer id it could be allocated by either end point of 
the connection or it could be a combination so that 
each end allocates a certain part of the identifier: 

In the present invention it is also assumed 
that the multiplexing of HS-DSCH data streams are pro- 

3 5 vided above transport layer i.e. in FP/MAC layer. 

The benefits of the invention can be summa- 
rised as follows: the available transport capacity 
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(i.e., bandwidth) is better utilised due to the im- 
proved statistical sharing of the bandwidth. The num- 
ber of transport bearers, e.g. AAL2 (ATM Adaptation 
Layer 2} connection is reduced as one bearer can be 
5 shared by several user streams . The frequency of 
transport bearer setups and tear-downs is signifi- 
cantly decreased as there is no need to have a dedi- 
cated bearer for each user stream. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are included 
to provide a further understanding of the invention 
and constitute a part of this specification, , illus- 
15 trate embodiments of the invention and together with 
the description help to explain the principles of the 
invention. In the drawings: 

Fig 1 is a block diagram illustrating an ex- 
ample of the state of the art scenario relating to the 

2 0 present mobile network; 

Fig 2 is a general protocol model for UTRAN 
interfaces of figure 1; 

Fig 3 describes a radio interface protocol 
architecture of HDSPA; 
25 Fig 4 is a signalling chart describing one 

embodiment of the present invention; and 

Figs 5 is - a signalling chart describing an- 
other embodiment of the present invention, 

DETAILED DESCRIPTION OF THE IHVENTIOH 

3 0 Reference will now be made in detail to the 

embodiments of the present invention, examples of 
which are illustrated in the accompanying drawings. 

In figures 4 and 5 is disclosed five network 
elements. Two of these elements are named twice , i*e, 
35 Hode B / DRNC and Node B / SRNC. This naming is done 
because these two figures are describing only two ex- 
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amples of the present invention and these same ele- 
ments could represent also the other element in the 
labelling. 

In figure 4 is disclosed a signalling chart 
5 describing an example case wherein Node B decides not 
to use an existing transport bearer resource. In fig- 
ure 4 Serving Radio Network Controller SRHC decides to 
setup a KS-DSCH channel, item 1. After this decision 
it sends a Radio Network Subsystem Application Part 

10 (RNSAP, ) message requesting Radio Link Setup, item 2. 
The parameter in this message is [Mux Indication IE] • 
This Mux Indication IE can have the following values : 
"may 11 or "shall not" in the request message. In case 
of "may", receiver can decide whether it will multi- 

15 plex or not. But in case of "shall not" receiver can- 
not use multiplex option. The message is sent to Drift 
Radio Network Controller DRNC. 

After this Drift Radio Network Controller 
DRNC sends a Node B Application Part message (NBAP) 

20 requesting Radio Link Setup to Node B, item 3, The pa- 
rameter also in this message is [Mux Indication IE] . 
Node B then checks if there is available transport 
bearer for a new Radio Link, item 4. In this case it 
detects that there exists no suitable transport bearer 

25 and a new transport bearer is needed. Then Node B 
sends a Radio Link Setup Response to DRNC to inform 
DRNC the parameters of the new transport bearers it 
has decided to establish. The parameters are [Trans- 
port Nearer Id IE, Binding ID IE, Transport Layer Ad- 

30 dre&s IE] , item 5. Based on the information from Node 
B, DRNC decides to setup a new transport bearer, item 
6 . Finally DRNC sends a Radio Link Setup Response with 
parameters [Transport Bearer Id IS, Binding ID IE, 
Transport Layer Address IE] to SRNC. 

35 In figure 5 is disclosed a signalling chart 

describing an example case wherein Node B decides to 
use an existing transport bearer resource. In figure 5 
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Serving Radio Network Controller SRNC decides to setup 
a HS-DSCH channel, item 1, After this decision it 
sends a Radio Network Subsystem Application Part 
(RNSAP,) message requesting Radio Link Setup, item 2. 
5 The message is sent to Drift Radio Network Controller 
DRNC. The parameter in this message is [Mux: Ind.iaa.tion 
XE] This Mux Indication IE can have the following 
values: "may" or "shall not 11 in the request message. 
In case of "may", receiver can decide whether it will 

10 multiplex or not- But in case of "shall not" receiver 
cannot use multiplex option. Drift Radio Network Con- 
troller DRNC sends a Node B Application Part message 
(NBAP) requesting Radio Link Setup to Node B, item 3, 
The parameter also in this message is [Mux Indication 

15 IE], Node B then checks if there is available trans- 
port bearer for a new Radio Link, item 4. In this case 
it detects that there exists a suitable transport 
bearer and no new transport bearer is needed. Then 
Node B sends a Radio Link Setup Response to DRNC with 

20 parameter [Transport Bearer Id IE] informing the ex- 
isting transport bearer that is to be used for this 
new data stream, item 5. Based on the information from 
Node B, DRNC decides not to setup a new transport 
bearer and instead of that uses an existing transport 

25 bearer that has been indicated with transport bearer 
id, item 6 -Finally DRNC sends a Radio Link Setup Re- 
sponse with parameter [Transport Bearer Id IE] to 
SRNC. This is all what is needed because SRNC will use 
an existing transport bearer and it already has the 

3 0 necessary parameters for this bearer. 

The allocating for the transport bearer iden- 
tification code or transport bearer id can be done in 
three ways. An originating RNC allocates the transport 
bearer id when a new transport bearer for RS-DSCH is 

3 5 needed between RNC and RNC/Node B and includes the 
transport bearer id to the message requesting HS-DSCH 
establishment /modif ication. When receiving node (Node 
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B or DRNC) gets the new transport bearer id it stores 
it (with other transport layer related information} 
and returns the transport bearer id back to the origi- 
nating node with allocated transport layer informa- 
5 tion. 

When receiving Node B/RNC gets a Radio Link 
Setup Request for a HS-DSCH channel from RMC without 
the transport bearer id, it allocates the id and in- 
cludes it with the transport layer information to re- 

10 ply message and stores the transport bearer id with 
correct transport layer information. 

In the third option both ' originating and re- 
ceiving network node allocates a part of the transport 
bearer id. In this case RNC allocates the first part 

15 of the transport bearer id when a new transport bearer 
for HS-DSCH is needed between RHC and RNC/Hode B and 
includes the part of the transport bearer id to the 
message requesting HS-DSCH establishment /modi f ication. 
After receiving the first part of the transport bearer 

20 id the receiving node allocates the other part of the 
id and stores the whole transport bearer id (with 
other transport layer related information) and returns 
the transport bearer id back to originating node with 
allocated transport layer information. 

25 The transport bearer id is stored in both 

nodes as long as the transport bearer it identifies 
exists . 

It is obvious to a person skilled in the art 
that with the advancement of technology, the basic 
3 0 idea of the invention may be implemented in various 
ways and in various network environments The invention 
and its embodiments are thus not limited to the exam- 
ples described above, instead they may vary within the 
scope of the claims. 
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CLAIMS 

1- A method for multiplexing a data stream 
onto a transport bearer between an originating network 
node and a receiving network node in a telecommunica- 
5 tions network, the method comprising the steps of 

mapping a transport bearer resource for a 
data stream, characterised in that the method 
further comprises the following steps: 

checking if there is available transport 
10 bearer resources in the group of existing transport 
bearers, and 

if there exists a transport bearer resource 
that can be used for said data stream, reserving said 
existing transport bearer resource for said data 
15 stream, or 

requesting a new transport bearer resource, 

and 

reserving said new transport bearer resource 
for said data stream. 
20 2. The method according to claim 1, char- 

acterised in that identifying said new transport 
bearer resource with a transport bearer identification 
code, 

3. The method according to claim 2 f char- 
25 acterised in that in said requesting step, indi- 
cating an existing transport bearer resource for said 
data stream by including said transport identification 
code in a request message. 

4. The method according to claim 1, char- 
30 acterised in that in said requesting step, indi- 
cating a need for a new transport bearer resource by 
sending a request message in which no transport identi- 
fication code is included. 

5. The method according to claim 2, char- 
35 acterised in that in using a unique transport 

bearer identification code, said transport bearer iden- 
tification code being unique at least between said 
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originating network node and said receiving network 
node , 

6, The method according to claim 2, char- 
acterised in that recording said transport 

5 bearer identification code at least for a lifetime of 
said transport bearer resource in both said originating 
network node and said receiving network node, 

7 . The method according to claim 2, char- 
acterised in that allocating said transport 

10 identification code in said originating network node. 

8. The method according to claim 2, char- 
acterised in that allocating said transport 
identification code in said receiving network node. 

9, The method according to claim 2, char- 
15 acterised in that allocating a first part of 

said transport identification code in said originating 
network node and a second part in said receiving net- 
work node, said first and second part constituting a 
whole transport bearer identification code. 

2 0 10, The method according to claim 1, char- 

acterised in that in said requesting step indi- 
cating if the multiplexing of said data stream is al- 
lowed or not, 

11. A method for multiplexing a data stream 

25 onto a transport bearer over the Xur and lub inter- 
faces between Serving Radio Network Controller (SMvTC) 
and Drift Radio Network Controller {D-RNC) or Node B 
in an IP Radio Access Network 

mapping a transport bearer resource for a 

30 data stream, characterised in that the method 
further comprises the following steps: 

checking if there is available transport 
bearer resources in the group of existing transport 
bearers, and 

35 if there exists a transport bearer resource 

that can be used for said data stream, reserving, said 
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existing transport bearer resource for said data 
stream, or 

requesting a new transport bearer resource, 

and 

5 reserving said new transport bearer resource 

for said data stream. 

12. The method according to claim 11, 
characterised in that identifying said new 
transport bearer resource with a transport bearer iden- 
10 tification code by introducing a new transport bearer 
id information element (IE) in NBAP/RNSAP messages. 

13 . The method according to claim. .12 , 
characterised in that in said requesting 
step, indicating an existing transport bearer resource 
15 for said' data stream by including said transport iden- 
tification code in a request message from Radio Network 
Controller or Node B* 

14. The method according to claim 11, 
characterised in that in said requesting 

20 step, indicating a need for a new transport bearer re- 
source by sending a request message in which no trans- 
port identification code is included. 

15. The method according to claim 12, 
characterised in that in using a unique 

25 transport bearer identification code, said transport 
bearer identification code being unique at least be- 
tween said Serving Radio Network Controller (SRNC) and 
said Drift Radio Network Controller (D-RNC) or said 
Node B 

3 0 16. The method according to claim 12, 

characterised in that recording said trans- 
port bearer identification code at least for a lifetime 
of said transport bearer resource in both said Serving 
Radio Network Controller (SRNC) and said Drift Radio 

3 5 Network Controller (D-RNC) or said Node B. 

17. The method according to claim 12, 
characterised in that allocating said trans- 
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port identification code in said Serving Radio network 
Controller (SRNC) . 

18. The method according to claim 12, 
characterised in that allocating said trans- 

5 port identification code in said Drift Radio Network 
Controller (D-RNC) or said Node B. 

19. The method according to claim 12, 
characterised in that allocating a first part 
of said transport identification code in said Serving 

10 Radio Network Controller (SRMC) said Drift Radio Net- 
work Controller (D-RUC) or said Node B ♦ 

20. The method according to claim 1, char- 
acterised in that in said requesting step indi- 
cating if the multiplexing of said data stream is al- 

15 lowed or not , 
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